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REMARKS 

Claims 1-9 and 1 1-13 were rejected pursuant to 35 U.S.C. §112, first paragraph. The 
Examiner alleges that: the look-up table conversion from 2D display format to a 2D acquisition 
format is not shown since the acquisition format is a 3D data volume, and the 2D acquisition 
format with avoiding scan conversion of volume data not contributing to a final volume image 
is self contradictory. 

Claim 1 has been amended to remove the "two-dimensional" acquisition format. Claim 
1 and the corresponding dependent claims 2-9 and 1 1-13 are supported by the original 
disclosure. 

Claims 14-20 and 22-27 were rejected pursuant to 34 U.S.C. §101 as being directed to 
non-statutory subject matter. Both claims 14 and 22 are directed to statutory subject matter. 
The transformation of data representing a patient into an image is directed to statutory subject 
matter (See In re Bilski ). 

In response, the Examiner alleges the claim is directed to change in format of data that 
has already been collected, so is not statutory. The Examiner notes that the steps of 
identification and interpolation are not tied to a machine. 

Independent claims 14 and 23 have been amended to require that the look-up table is in 
a memory and a processor performs the interpolating. These method claims are tied to a 
statutory class, so are directed to statutory subject matter. 

In the Office Action, the Examiner again rejected claims 1, 3, 5, 11-14, 16, 18, and 24- 
26 pursuant to 35 U.S.C. §103(a) as unpatentable over Halmann, et al. (US 6,526,163) in view 
of Seiler, et al. (EP 1,093,085). Claim 2 was rejected pursuant to 35 U.S.C. § 103(a) as 
unpatentable over Halmann, et al. in view of Seiler and further in view of Zar (A Scan 
Conversion Engine...). Claims 4 and 17 were rejected pursuant to 35 U.S.C. §103 (a) as 
unpatentable over Halmann, et al. in view of Seiler, et al and Hossack, et al. (US 6,352,51 1). 
Claims 6 and 19 were rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et 
al. in view of Seiler, et al. and Okerlund, et al. (US 6,690,371). Claims 7 and 20 were rejected 
pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of Seiler, et al. and 
Drebin, et al. (US 4,835,712). Claims 9 and 22 were rejected pursuant to 35 U.S.C. § 103(a) as 
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unpatentable over Halmann, et al. in view of Seiler, et al. and Swerdloff (US 5,483,567). Claim 
15 was rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of 
Seiler, et al. and Fattah (US 7,274,325). Claim 27 was rejected pursuant to 35 U.S.C. § 103(a) 
as unpatentable over Halmann, et al. in view of Seiler, et al. and Edic, et al. (US 2004/0136490). 

Claim 10 was allowed. Claim 21 was objected to as being allowable if amended into 
independent form. 

Applicants respectfully request reconsideration of the rejections of claims 1-9, 1 1-20, 
and 22-27, including independent claims 1 and 14. New remarks are provided below in italics. 

Independent claim 1 recites a processor operable to identify acquired ultrasound data as 
a function of the values where a look-up table has the values corresponding to a spatial 
conversion from the display format to the acquisition format. 

Halmann, et al. do not disclose this limitation. Halmann, et al. note that a CPU 
generates the scan converter tables necessary to convert scanned data from the polar coordinate 
system to the Cartesian coordinate system where the tables are dependent on the mode of 
operation (col. 7, lines 54-59). Scan conversion is performed with interpolation and the like 
(col. 8, line 53-col. 9, line 4). Halmann, et al. do not provide further details for the tables, but 
indicate that the tables convert the data. Halmann, et al. do not use values of the table to 
identify ultrasound data. There is no teaching that acquired ultrasound data is identified as a 
function of the values of the look-up table. 

The tables of Halmann, et al. would be used by applying each ultrasound datum to the 
table. The table then provides for conversion of the ultrasound data. Each datum is converted, 
so the identity of a given ultrasound datum is not needed. The original data is converted 
regardless of identity. 

Claim 1 recites that the table has values corresponding to a spatial conversion from the 
display format to the acquisition format. Halmann, et al. convert polar coordinates into 
Cartesian coordinates (col. 7, lines 55-57; and col. 8, lines 64-65), not a look-up table used 
for the inverse conversion of Cartesian coordinates to the polar coordinates. 

The Examiner alleges that, since the scan conversion is converting the polar scanned 
data to display values, it is identifying the polar data as a function of the Cartesian values, 
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and alleges that the look-up table is reversible. However, Halmann, et al. do not disclose the 
structure of the lookup table. The lookup table, to be used for scan conversion, likely has 
interpolation values (not a Cartesian coordinate) given an input Polar coordinate. The 
interpolation values are then applied to the data for that Polar coordinate to weight the data 
and create Cartesian data. The table is likely for interpolation values for the actual 
conversion of data at particular coordinates, so would not have a Cartesian coordinate output 
given a polar coordinate input. 

Even if the table is addressed by scan coordinates, to use inversely, the specific 
interpolation values, not a Cartesian coordinate, would be needed to address the table. For 
example, the table would be addressed by polar coordinate to output interpolation weights 
(e.g., 0.93). These interpolation values correspond to spatial relationships, so may be 
identical for different locations. Using the table in reverse would result in multiple polar 
coordinates given an input interpolation value. 

Even if reversible, Halmann, et al. convert polar coordinate data to Cartesian coordinate 
data. There is no reason to identify polar coordinate data from or starting with a Cartesian 
coordinate. The process flows by providing polar coordinate data. The polar coordinate data is 
then interpolated (weighted and summed) to represent data at a Cartesian coordinate. The 
location of the Cartesian coordinate does not need to be known before hand. The available 
polar coordinate data is converted. An inverse lookup would not occur. 

The Examiner points out that Halmann, et al. disclose interpolation with respect to the 
lookup table. Applicants agree. However, the tables are created to "convert scanned data 
from the polar coordinate system to the Cartesian coordinate system" (col. 7, lines 54-57). 
This is done for converting incoming data from the polar coordinate system to the Cartesian 
coordinate system (col. 6, lines 10-12). It is hindsight, in light of this specific teaching to 
convert from polar to Cartesia, or, to suggest conversion from Cartesian to polar. Halmann, et 
al. do not suggest reverse lookup. The system is not configured for reverse lookup. 

Independent claim 1 further recites that the processor is operable to avoid scan- 
conversion of volume data that does not contribute to a final volume rendered image, the 
identifying corresponding to identifying for display format coordinates associated with 
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visible voxels of the final volume rendered image. Halmann, et al. and Seiler, et al. do not 
disclose these limitations. 

Halmann, et al. simply scan converts all the incoming polar coordinate values for 
imaging. All the scan conversion tasks are completed so that a 2D image is generated (col. 9, 
lines 4-13). Volume rendering is performed from the 2D images (col. 5, lines 34-40). 
Halmann, et al. rely on polar coordinate to Cartesian coordinate scan conversion, converting 
all of the frames of data to provide 2D images, and then perform volume rendering from the 
2D images. Halmann, et al. do not operate scan conversion as a function of the volume 
rendering, so do not avoid scan-conversion of volume data that does not contribute to a final 
volume rendered image, the identifying corresponding to identifying for display format 
coordinates associated with visible voxels of the final volume rendered image. 

The Examiner takes a mere general statement about generating scan conversion tables 
and alleges obviousness of the claim, indicating hindsight reasoning. 

Seiler, et al. also do not avoid scan conversion. As known in the art and recited in the 
claim, scan conversion corresponds to a spatial conversion from an acquisition format to a 
two-dimension display format. Seiler, et al. do not disclose scan conversion. Instead, a 
volume of data is the starting point (paragraphs 2, 8, and 34-35). Volume sections are 
reviewed to avoid transfer for 3D rendering of 3D voxels. Seiler, et al. start with volume 
data and avoid 3D rendering of voxels, so do not avoid scan conversion. 

The Examiner notes that the concept of skipping unviewable sections of a volume is 
applicable to both ray tracing and scan conversion, so a person of ordinary skill in the art 
would apply it to scan conversion. However, neither Seiler, et al. nor Halmann, et al. 
connect this concept of avoiding scan conversion with reverse lookup. Halmann, et al. do 
not disclose reverse lookup (i.e., conversion of display coordinates to acquisition 
coordinates). Seiler, et al. use visibility tests as part of ray casting (paragraphs 29 and 30). 
Seiler, et al. test cut-planes (paragraph 55), cropping boundaries (paragraph 55), depth test 
(paragraph 56), early ray termination (paragraph 61), and space leaping (paragraph 66) to 
identify voxels that do not need to be loaded. Seiler, et al. do not determine visibility by 
identifying acquisition data from display coordinates. The two references scan convert and 
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then render with the converted volumes. Seller, et al. test visibility on the volume data. The 
two references do not disclose a processor configured to avoid scan-conversion of volume 
data that does not contribute to a final volume rendered Image, the Identifying corresponding 
to Identifying for display format coordinates associated with visible voxels of the final 
volume rendered Image . 

A person of ordinary skill in the art would not have used the avoidance of transfer of 
voxels with the scan conversion of Halmann, et al. Seiler, et al. use as input a volume set of 
data. Halmann, et al. generates 2D images by scan conversion (col. 9, lines 4-13). A 
collection of the scan converted images are used to form a volume data set for rendering, 
(col. 5, lines 33-40). Halmann, et al. treat scan conversion and rendering separately. A 
person of ordinary skill in the art would have used the voxel control for rendering of Seiler, 
et al. with the rendering of Halmann, et al., not the different scan conversion process. 

A person of ordinary skill in the art would not have used the voxel transfer avoidance 
of Seiler, et al. with the scan conversion of Halmann, et al. for another reason - failure to 
enable. Seiler, et al. rely on the data in a volume arrangement or volume sections extracted 
from the volume data to determine which voxels not to use. The view direction, size of the 
volume, equations for cut and crop planes in the volume, and bounding boxes are volume 
related factors used to select voxels (paragraphs 77 and 78). The volume data set is needed 
to even determine these factors. As of the scan conversion of Halmann, et al., the volume 
data set is not yet created. A person of ordinary skill in the art would not know how to use 
voxel selection in the scan conversion process since Seiler, et al. provide a process for a 
rendering pipeline with the volume data as a starting point. 

The Examiner alleges that the combined teachings would improve efficiency by 
bringing the extra rendering avoidance techniques of Seller, et al. in to Halmann, et al. 
First, the techniques of Seller, et al. do not Involve Identifying acquisition data by conversion 
from display coordinates associated with visible voxels. Seller, et al. Identify voxels that are 
or are not visible regardless of the display coordinates. Second, porting just the concept of 
avoidance to Halmann, et al. does not provide a way for Implementing this In Halmann, et al. 
except In the post scan conversion rendering of Halmann, et al. Halmann, et al. scan convert 
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all, and then use the scan converted data as a volume for rendering. Seller, et al. teach 
visibility testing in rendering. If combined, the rendering teaching of Seller, et al. would be 
used in the rendering of Halmann, et al. The rendering of Halmann, et al. Is Independent of 
and occurs after the scan conversion. 

Using 3D rendering voxel transfer avoidance of Seiler, et al. in the scan conversion of 
Halmann, et al. is using improper hindsight reasoning. 

The inventor, Gianluca Paladini (inventor of 10 patents), drafted his own remarks 
provided in this and the following paragraphs in italics. In Halmann et al. (US 6,526,163), 
there Is a clear separation between a scan conversion module 207 and a volume rendering / 
ray casting module 201. Halmann teaches that a "scan converter module 207 converts 
incoming data from the Polar coordinate system to the Cartesian coordinate system. The 
foregoing modules 201-208 may divide the operations associated with each module Into 
tasks..." (column 6, lines 10-14). Such sentence indicates that " foregoing " module 201 Is 
used after module 207. 

Halmann describes a "volume rendering / raycasting module 201 constructs a 3- 
dlmenslonal volume from a series of 2 -dimensional images. The module 201 then performs 
known volume rendering and/or raycasting techniques to produce an image for display" 
(column 5, lines 34-38)(emphasis added). Such sentence indicates that an entire 3- 
dimenslonal volume is constructed before rendering, and " then " rendering takes place. 

Current claim 1 describes a very different approach, whereby scan-conversion takes 
places during volume rendering (not before as in Halmann et al.) as a function of the values 
being Interpolated, and that scan conversion of volume data that does not contribute to a 
final volume rendered Image Is avoided. This approach is much more efficient than the one 
suggested by Halmann' s et al., due to avoiding scan-conversion of the entire volume data 
before rendering the volume. Halmann does not teach that the process of volume rendering 
can be used to selectively determine what is visible in order to avoid unnecessary scan- 
conversion computations. 

In Halmann 's claims 1-3, It Is evident that scan conversion Is Its own separate 
process, where Halmann suggests scan conversion can be divided into parallel scan 
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conversion tasks. His solution to the problem of having to scan convert all the volume data 
suggests the use of parallel processing tasks distributed onto multiple CPUs, while the 
solution of current claim 1 is to avoid unnecessary scan-conversion computations in the first 
place. Note also that in Halmann's method, scan conversion is separate from rendering and 
display and therefore scan conversion is implicitly view-independent. The solution of current 
claims 1 is implicitly view -dependent as illustrated in Figure 5a of our application. Since 
only the visible samples con tributing to a given view of the volume are scan-converted in 
claim 1, different samples are scan converted every time the arbitrary observer location 
501 changes. Halmann 's method would not provide for such change. 

Setter describes known methods for skipping over voxels or samples that are explicitly 
clipped ("pruning"), obscured by other parts of the volume ("early ray termination" ), or 
transparent parts of the volume ("empty space skipping"). These concepts are not his 
original ideas, as they have been known in the art of volume rendering and described in a 
back as early as 1990. What Setter is suggesting is that such methods are easy to implement 
in software but are very difficult to implement in hardware. The method he describes in EP 
1,093,085 therefore focuses on a particular hardware apparatus for volume rendering. As 
evident in Setter's claim 1, 5 and 6, the volume data already exists and it is partitioned into 
various sections and blocks for visibility tests. Therefore, Setter's apparatus is relying on 
volume data that already exists in the form of a three-dimensional volume containing voxels 
before rendering can take place. In the system of current claim 1, the three dimensional 
volume does not exist yet, because the voxel values of the three dimensional Cartesian 
volume being rendered have not been scan-converted yet. Sample values are scan-converted 
on the fly selectively by converting Cartesian coordinates to Polar coordinates for each 
visible sample along a ray passing through a "virtual" Cartesian volume (see description 
[ 0091 ] and [0102] in our application), so that polar data values can be interpolated. This 
approach is very different from Setter's, where samples are interpolated from existing 
Cartesian voxel values. 

Note also that in Setter's method, since voxel values are assumed to already exist 
before rendering, such method is implicitly view-independent. The solution of claim 1 is 
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implicitly view -dependent as illustrated in Figure 5a of our application. Since only the 
visible samples contributing to one view of the volume are scan-converted, different samples 
are scan converted every time the arbitrary observer location 501 changes. 
To summarize: 

1) Claim 1 is implicitly view-dependent, because samples are scan converted based on a 
particular observer position associated with the volume rendered image; the prior art scan 
converts first and THEN renders, therefore they do not need to scan convert again when the 
observer position changes; however they have to scan convert ALL data, while claim 1 scan 
converts data selectively and in an inverse way (cartesian to polar). Each approach has its 
PROs and CONs: their method takes longer to perform scan conversion because they have to 
scan convert all data, but then it perform faster at rendering time because they do not have 
to scan convert again if they are simply moving the orientation of the camera around the 
volume; our method saves processing time by not scan converting all polar data upfront, 
instead it selectively scan converts only visible samples for a particular position of the 
observing camera, however rendering performance is not as fast when the observer's 
position changes, as we have to selectively scan convert new samples again. 

2) The prior art scan converts data from polar to cartesian - which involves a first 
interpolation step possibly using a look-up table, and then renders an ACTUAL cartesian 
volume - which involves a SECOND interpolation step using cartesian voxel data. The 
system of claim 1 has a "virtual" cartesian volume with no data in it, and a SINGLE 
interpolation step which is computed by converting cartesian coordinates to polar 
coordinates and interpolating polar data is provided. 

Independent claim 14 is allowable for similar reasons as claim 1. 

Dependent claims 2-7, 9, 1 1-13, 15-20, 22, and 24-27 depend from claims 1 and 14, and 
are allowable for the same reasons as the corresponding base claim. Further limitations 
patentably distinguish from the cited references. 

Claim 2 recites that the values comprise Polar coordinates, the look-up table entries 
indexed by integer Cartesian coordinates and wherein the processor is operable to bilinearly 
interpolate from the look-up table values using fractional offsets of Cartesian coordinates. 
- 15- 
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As noted by the inventor, Halmann states that a "scan converter module 207 converts 
incoming data from the Polar coordinate system to the Cartesian coordinate system " 
(column 6, lines 10-1 2 )( emphasis added). Base claim 1 provides that samples passing 
through a "virtual" Cartesian volume are scan-converted by converting Cartesian 
coordinates to Polar coordinates, thereby the interpolation takes place in the Polar 
coordinate system - the opposite of what Halmann and Zar disclose. Claim 2 depends on 
Claim 1, where we have shown that Seller does not teach the concept of a virtual Cartesian 
volume - instead he assumes that Cartesian voxel data already exists. 

Claims 3 and 16 recite determining the display coordinates of interest and identifying 
the acquired ultrasound data by input of the display coordinates into the look-up table. The 
Examiner cites to col. 8, lines 4-9 of Halmann, et al. Halmann, et al. may locate an area of 
interest, but the area is not used to identify acquired data by input into the look-up table. 
Identifying all ultrasound data is not using the area to identify data. 

The Examiner alleges that all the data is the area of interest. However, Halmann, et 
al. do not provide a process for less than all data being the area of interest. Accordingly, 
Halmann, et al. do not provide for identifying acquired data by input of determined display 
coordinates. 

Claims 5 and 18 recite the display coordinates of interest input to the look-up table 
being coordinates for a plurality of rays through the volume. Halmann, et al. disclose a 
raycasting/volume rendering module 201, but this module 201 is not shown to work with the 
tables of the separate scan conversion module 207. The Examiner alleges there is no way to 
render an image if the original coordinates are polar, but that is not true. The rendering can 
account for any coordinate system. The rendering, rather than scan conversion, may provide 
data for each pixel based on ray casting, regardless of the format of the input data. Halmann, 
et al. do not put ray coordinates into a scan conversion look-up table. 

The Examiner notes that Halmann, et al. disclose lookup tables for scan conversion, 
so one skilled in the art would use tables with raycasting. However, Halmann, et al. treat 
rendering and scan conversion separately. Rendering, unlike scan conversion, is not 
disclosed as using tables. Instead, raycasting is used with interpolation along the rays. The 
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interpolation to the rays and then blending provides the pixel values. 

Claim 26 recites generating a two-dimensional look-up table with acquisition format 
coordinates for each coordinate of a Cartesian volume. Halmann, et al. treat volume 
rendering separately from scan conversion. There is no disclosure of a LUT for coordinates 
of a Cartesian volume. The Examiner alleges there is no way to render an image if the 
original coordinates are polar, but that is not true. The rendering can account for any 
coordinate system. Also, the process of Halmann, et al. may be used - convert from Polar to 
Cartesian. The image is rendered from a volume of Cartesian data, so a reverse table would 
not be used. 

Halmann, et al. treat rendering and scan conversion separately. Rendering, unlike 
scan conversion, is not disclosed as using tables. Instead, ray casting is used with 
interpolation along the rays. The interpolation to the rays and then blending provides the 
pixel values. 

Claim 4 recites the processor operable to determine a plane through a volume as the 
display coordinates where the display coordinates are input to the look-up table. Hossack, et 
al. show arbitrary plane display for a volume, but do not use the coordinates of the plane as 
an input to the look-up table. Halmann, et al. treat volume rendering and scan conversion 
separately, so do not use coordinates of a plane in a volume as input to the scan conversion 
table. The form of conversion used would be the form taught by Halmann, et al, not a 
reverse conversion that also intermixes the separate rendering process. Claim 17 is allowable 
for similar reasons. 

The Examiner points out that some sort of conversion must be done to obtain display 
data and Halmann, et al. use the LUT for conversion. However, rendering a plane from a 
volume is not handled as scan conversion by Halmann, et al. In rendering, the display 
values are interpolated from the already scan converted volume. Hossack, et al. shows scan 
conversion of 2D planes, such as performed by Halmann, et al. Halmann, et al. then 
perform rendering from the collected planes. A LUT is not disclosed as being used for 
rendering. The data is already in a Cartesian format. 

As noted by the inventor, by association with Claim 1, claims 4 and 17 imply that the 
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cross-section is also computed by selective scan-conversion of only the samples required to 
form the image plane, as illustrated in Figure 5b of the application. Hossack describes a 
scan converter 34, stating "the scan converter comprises a device for reformatting polar 
coordinate ultrasound data into Cartesian coordinate ultrasound data" (column 5, lines 62- 
65), which is described as a separate module from the subsequent display step 36. Hossack 
does not teach a combined display and scan-conversion process where scan-conversion 
selectively skips samples which do not contribute to the final image. Hossack also does not 
teach the use of a "virtual" Cartesian volume which does not contain any voxel data - in 
fact, claims in Hossack focus solely on a method for persistence of ultrasound data, the 
opposite of our approach where no Cartesian volume data is ever persisted, and new 
samples are always scan-converted on the fly based on a particular observer location. 

Claims 6 and 19 are allowable for the same reasons as claim 5. Claims 6 and 19 are 
also allowable because Okerlund, et al, like Halmann, et al. and Seller, et al, do not treat 
rendering and scan conversion together. A collection of images or display formatted data is 
used to form the volume (col. 3, lines 47-60). 

As noted by the inventor, by association with the base claims, claim 6 and 19 
selectively avoid scan-conversion of volume data that does not contribute to a final volume 
rendered image. In 6,690,371, Okerlund describes a typical setup of a medical imaging 
workstation with a rendering component 86 which can visualize acquired medical data. 
Commercial systems as such have been available decades before Okerlund' s filing date of 
May 3, 2000 and his description of the rendering component does not teach anything new 
other than one very particular idea, which was incorporated in the claims, where the 
visualization comprises the rapid production of a "reduced-fidelity" image by using a 
"decimated image volume " which gets refined to a full-fidelity image in subsequent steps. 
Okerlund does not teach the idea of sampling a "virtual" Cartesian volume and selectively 
scan-convert only the samples that contribute to the final image through inverse look-up. In 
addition, the recited system does not rely on decimated "reduce-fidelity" data - in fact, the 
claimed approach produces results that are superior even to the "full-fidelity" images 
described by Okerlund, and superior to images which would be produced by Halmann and 
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Seiler. By scan-converting data prior to rendering, Halmann relies on existing voxel values 
in a Cartesian dataset, and therefore during rendering his method interpolates Cartesian 
voxel values. Such values have already undergone a previous interpolation step from Polar 
to Cartesian in the .scan converter module, therefore Halmann' s approach interpolates two 
limes and as a result the image quality is blurrier. Seiler perform the same multiple 
interpolation. In the recited approach of claims 6 and 19, the "virtual" Cartesian volume 
does not contain any data, and each sample is interpolated on the fly only once from Polar 
data - we therefore have one less interpolation step, and the image quality is improved 
compared to systems relying on Halmann, Okerlund, and Seiler. 

By association with claims 1 and 14, claims 9 and 22 selectively avoid scan- 
conversion of volume data not contributing to the final image. Swerdlojf does not teach a 
method for selective scan conversion of volume data. Swerdloff teaches a method for 
converting Polar data in a tomographic reference frame to Cartesian data ("Polar to 
Cartesian Conversion" section in Swerdloff patent), the opposite transform as the one used 
in our application. The method converts all Polar data and does not selectively discard data 
that does not contribute to the final image: this is illustrated in Fig. 3, step 50 ("for each 
polar voxel") which is the outer loop controlling the entire conversion process. In addition, 
due to the fact that Polar data is being converted to Cartesian with a method known in the 
art as "forward mapping ", Swerdloff s method has no choice but to truncate Polar volume 
elements against the overlapping Cartesian volume elements and sum the resulting areas of 
truncated volume elements with appropriate weight values. Our method relies on "inverse 
mapping" from Cartesian to Polar, therefore we do not require to compute such truncated 
overlapping areas. 

Claim 12 recites a flag, and an integer sum. As noted in the specification, an integer 
sum allows indication of spatial relationship relative to other table entries. Halmann, et al. 
do not suggest any format for the look-up table, and certainly do not disclose an integer sum, 
a flag or fixed-point values. These values are chosen to allow table based identification of 
data rather than scan conversion of the data. Selective scan conversion of only the samples 
that contribute to the rendering result without having to scan convert occluded data is 
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provided by the recited table variables. A person of ordinary skill in the art would not have 
provided the listed classes as a mere design choice. The flag and integer sum would not have 
been considered as there is no reason for them in Halmann, et al. Just being well known is 
insufficient. 

The Examiner notes that there is no reason to use a flag and integer sum in Halmann, 
et al. and alleges the same for the invention, so that they are a design choice. The Examiner 
then alleges that the claimed invention does not recite indication of a spatial relationship 
and that other variables may work. However, the claimed invention is about scan 
conversion, which is a spatial relationship. The flag and integer sum efficiently track 
visibility for the claimed reverse lookup. Given the teachings of Halmann, et al., a person of 
ordinary skill in the art would not have used the flag and integer sum as a design choice. 



Applicants respectfully submit that all of the pending claims are in condition for 
allowance and seeks early allowance thereof. 

PLEASE MAIL CORRESPONDENCE TO: Respectfully submitted, 
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